1. Technical Field
The present invention relates to the field of integration of applications; said applications being executed by computer systems.
2. Prior Art
Workflow technology is becoming more and more important for the integration of applications. It supports the modelling and execution of business processes. Business processes control which piece of work of a network of pieces of work will be performed by whom and which resources are exploited for this work, i.e. a business process describes how an enterprise will achieve its business goals. The individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
The process of designing, developing and manufacturing a new product and the process of changing or adapting an existing product presents many challenges to product managers and engineers to bring the product to market for the least cost and within schedule while maintaining or even increasing product quality. Many companies are realizing that the conventional product design process is not satisfactory to meet these needs. They require early involvement of manufacturing engineering, cost engineering, logistic planning, procurement, manufacturing, service and support with the design effort. Furthermore, they require planning and control of product data through design, release, and manufacturing.
The correct and efficient execution of business processes within a company, e. g. development or production processes, is of enormous importance for a company and has significant influence on company's overall success in the market place. Therefore, those processes have to be regarded similar as technology processes and have to be tested, optimized and monitored. The management of such processes is usually performed and supported by a computer based process or workflow management system (WFMS).
In D. J. Spoon: "Project Management Environment", IBM Technical Disclosure Bulletin, Vol. 32, No. 9A, February 1990, pages 250 to 254, a process management environment is described including an operating environment, data elements, and application functions and processes.
In R. T. Marshak: "IBM's FlowMark, Object-Oriented Workflow for Mission-Critical Applications", Workgroup Computing Report (USA), Vol. 17, No. 5, 1994, page 3 to 13, the object character of IBM FlowMark as a client/server product built on a true object model that is targeted for mission-critical production process application development and deployment is described.
In H. A. Inniss and J. H. Sheridan: "Workflow Management Based on an Object-Oriented Paradigm", IBM Technical Disclosure Bulletin, Vol. 37, No. 3, March 1994, page 185, other aspects of object-oriented modelling on customization and changes are described.
In F. Leymann and D. Roller: "Business Process Management with FlowMark", Digest of papers, Cat. No. 94CH3414-0, Spring COMPCON 94, 1994, pages 230 to 234, the state-of-the-art computer process management tool IBM FlowMark is described. The meta model of IBM FlowMark is presented as well as the implementation of IBM FlowMark. The possibilities of IBM FlowMark for modelling of business processes as well as their execution are discussed. The product IBM FlowMark is available for different computer platforms and documentation for IBM FlowMark is available in every IBM branch.
In F. Leymann: "A meta model to support the modelling and execution of processes", Proceedings of the 11th European Meeting on Cybernetics and System Research EMCR92, Vienna, Austria, Apr. 21 to 24, 1992, World Scientific 1992, pages 287 to 294, a meta model for controlling business processes is presented and discussed in detail.
The "IBM FlowMark for OS/2", document number GH 19-8215-01, IBM Corporation, 1994, available in every IBM sales office, represents a typical modern, sophisticated, and powerful workflow management system. It supports the modelling of business processes as a network of activities; refer for instance to "Modeling Workflow", document number SH 19-8241, IBM Corporation, 1996. This network of activities, the process model, is constructed as a directed, acyclic, weighted, colored graph. The nodes of the graph represent the activities or workitems which are performed. The edges of the graph, the control connectors, describe the potential sequence of execution of the activities. Definition of the process graph is via the IBM FlowMark Definition Language (FDL) or the built-in graphical editor. The runtime component of the workflow manager interprets the process graph and distributes the execution of activities to the right person at the right place, e.g. by assigning tasks to a work list according to the respective person, wherein said work list is stored as digital data within said workflow or process management computer system.
In F. Leymann and W. Altenhuber: "Managing business processes as an information resource", IBM Systems Journal, Vol. 32(2), 1994, the mathematical theory underlying the IBM FlowMark product is described.
In D. Roller: "Verifikation von Workflows in IBM FlowMark", in J. Becker und G. Vossen (Hrsg.): "Geschaeftsprozessmodellierung und Workflows", International Thompson Publishing, 1995, the requirement and possibility of the verification of workflows is described. Furthermore the feature of graphical animation for verification of the process logic is presented as it is implemented within the IBM FlowMark product.
For implementing a computer based process management system, firstly the business processes have to be analyzed and, as the result of this analysis, a process model has to be constructed as a network of activities corresponding to the business process. In the IBM FlowMark product, the process models are not transformed into an executable. At run time, an instance of the process is created from the process model, called a process instance. This process instance is then interpreted dynamically by the IBM FlowMark product.
Application integration basically means sharing of data between independently developed programs or programs which are mutually not aware of their existence. In general, to achieve sharing of data the affected applications must be changed. Consequently, methods are looked for which enable data sharing with as less changes as possible.
In a brief sketch the basic mechanisms used today to integrate applications are outlined below. This mechanisms are not exclusive but often used together.
The most wide-spread method for integrating applications is by introducing sharing of operational data, i.e. of data used and/or manipulated by the applications, between the applications. One method to achieve this is via mutual replication of operational data between the data stores of all affected applications. Another method is to migrate all affected data stores to a single one and rewrite the corresponding applications. A third method introduces a federated database like middleware allowing uniform access to the disparate data stores and rewriting all affected applications on top of this middleware.
A different kind of method found in practice is to integrate applications from an end-user perspective, i.e. by providing new EUIs for all applications to be integrated resulting in a common look-and-feel. Often, the functionalities of the affected applications are encapsulated and externalized in a uniform manner allowing the integration of applications in unforeseeable combinations (OpenDoc, OLE/OCX). In these environments, data are typically not shared (in the sense of accessing a common data store) but exchanged via volatile storage, e.g. via DDE or standardized interfaces for accessor methods.
More and more, WFMS are regarded as middleware for application integration. Their dataflow mechanisms allow applications to pass data to other applications in a uniform manner; this is exchange of data via persistent storage. For this purpose the applications must not be changed to run against a new interface of a new operational data store but it must be able to accept data from the WFMS or to pass data to the WFMS. Very often, the latter changes are considered to be acceptable when compared with the former changes.
Via the WFMS data is passed from one application to another by using the WFMS as the intermediate data store. Applications exchange data via so-called containers. The dataflow mechanism of a WFMS allows to specify the composition of the containers from fields of other containers. When an application gets invoked its input container is constructed based on these specifications and made available to the application. When an application terminates it passes its output via the output container to the WFMS which stores it into its own data store.
A principal problem in the area of application integration via MFMSs is that the amount of data passed from the application to the WFMS is often not appropriate. In such extreme cases applications either return no data at all to the WFMS or to much data.
Existing programs or programs being written as general purpose applications do not output data to a WFMS. Thus, the WFMS does not get the data which is needed by follow-on applications or by the WFMS for determining the next applications to be invoked. The consequences are twofold:
1. The integration features of the WFMS cannot be properly exploited, as a certain amount of data is read and stored via external interfaces from/to persistent storage making applications dependent on these interfaces. PA1 2. The control flow logic of the business process using the corresponding program as activity implementation cannot be properly expressed. This is because it must be based on the "return code" of the program but this mechanism was not invented for indicating business semantics. PA1 1. Containers become very large because many of the data will not be used by other applications at all, or some data members are very huge (e.g. a document or an image). PA1 2. Since the data in the containers are copies of operational data it becomes outdated: In general, during the time an application puts a data item in a container and another application reads the data from that container different applications modified the data already in the operational data store. Consequently, the container data and operational data run out of synchronization. PA1 materialization-means enhancing said input-container; said materialization-means being executed before said input-container is passed to said process-activity and said materialization-means performing materialization of said input-container by materializing said data-member by retrieving said data-member's contents from arbitrary storage areas and/or by manipulating said data-member's contents. The arbitrary storage areas are either internal or external the system. Moreover the materialization means may manipulate the data members' contents without any limitation.
Very frequently, when a WFMS is exploited explicitly for application integration the WFMS is misused as an operational database, i.e. the programs written as dedicated activity implementations tend to pass all data possibly needed by other applications in their output container. This has two consequences: